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(57) Abstract: This invention relates to the field of IP telephony. More particularly, this invention is a method and system for select- 
ing gateways for routing calls through a packet-based telecommunications network interconnected with a public telecommunications 
network. This invention is a method and system for dynamically detecting available gateways (1 10a, 1 10b), dynamically removing 
failed or unavailable gateways (1 10a, 1 10b), and automatically recovering failed or unavailable gateways after a predetermined pe- 
riod of time. An embodiment of this invention comprises two user agents (102, 103) within two telephony systems (1 14a, 1 14b) that 
are connected to an IP network (112); a plurality of gateways (1 10a, 110b); an IP telephony proxy server (106); an IP redirect server 
(104); and a network management system (108). 
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METHOD AND SYSTEM FOR DYNAMIC GATEWAY SELECTION 
IN AN IP TELE PHONY NETWORK 



10 BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates generally to the field of IP telephony, and more particularly 
to a method and system for selecting gateway(s) for routing calls through a packet-based 
telecommunications network interconnected with a public telecommunications network. 
15 Acronyms 

The written description herein uses a number of acronyms to refer to various services, 
messages and system components. Although generally known, use of several of these acronyms 
is not strictly standardized in the art. For purposes of this discussion, several acronyms will be 
defined as follows: 

20 Dynamic Gateway Selection (DGS) - a process employed by a network server and a 

Redirect Server (RS) to allow calls to be routed to an egress gateway. 
Egress (Destination) and Ingress (Origination) Gateways - gateways connecting an 
internet protocol network to a PSTN, PBX or other network. N 
Network Management System (NMS) - performs a variety of functions, including 

25 receiving and storing status changes to destination or egress gateways. 

Pescijptypn of tfre Prior Art 

Internet telephony provides real-time delivery of voice, and other multimedia data, 
between two or more panics across a network employing Internet protocols (IP). Internet 
telephony is session-based rather than connection-based. That is, Internet telephony uses virtual 
30 connections or circuits to pass data between two nodes. These connections between the nodes 
are termed "virtual circuits" to distinguish them from dedicated circuits of conventional 
networks. 
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While IP telephony offers benefits to both users and carriers in terms of costs and 
versatility of media carried, there are a substantial amount of traditional telephones being 
serviced by the Public Switched Telephone Network (PSTN). The PSTN provides users with 
dedicated, end-to-end circuit connections for the duration of each call. Circuits ate reserved 
between an originating switch and a terminating switch based on a called party number. 

However, because of the popularity of the Internet, many public telecommunication^ 
networks now carry significantly more TP data traffic than voice data traffic. Public 
telecommunications networks, optimized for voice traffic, are ill-equipped to handle increasing 
data traffic volumes. The growth in IP data traffic coupled with customer demands for integrated 
voice and data services at lower costs has led to the adoption of IP as the preferred protocols for 
carrying both voice and data traffic between originating and terminating switches of the public 
telecommunications network. 

Accordingly, in order for IP based telephony services to become broadly accepted by 
users of traditional telephones, it is necessary to interface the IP telephony network with the 
existing PSTN and with private PBX phone networks. To permit this mode of operation,* 
packet-based network, such as the Internet, must interface directly with public telephone 
networks and operate as a bridge between originating and destination switches of such networks. 

Media streams which originate from a public network must be capable of being 
transported through the packet-switched IP network and terminate at the same or different public 
network. This type of interfacing is performed by gateways which interface the signaling and 
bearer paths between the two networks. Therefore, Internet gateways perform code and protocol 
conversion between two otherwise incompatible networks to provide links necessary to send 
packets between the two different networks and thus make network-to-network connections 
possible. To assure overall system reliability it is crucial that the gateways arc reliable and their 
availability, especially destination or egress gateways, be monitored for quickly and efficiently 
selecting an available gateway. 

SUMMARY Off THE INVENTION 

In accordance with the principles of the invention, a method and system are provided by 
which an egress (i.e., destination) gateway is dynamically selected to establish a communication 
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session over a path supported at least in part by an IP telephony network and a PSTN. PBX or ; 
other network. A redirect server (RS) in concert with a network management system (NMS) 
employs a gateway selection methodology which incites recording egress gateways which are 
not available due to several reasons, such as having timed out. or having a malfunction, i.e.,; 

. t 

failure status. 

In one embodiment of the present invention, a method is provided for dynamically 
selecting an egress gateway to allow a call to be completed in a communication session over a 
path supported at least in pan by an IP telephony network and a PSTN. PBX or other network: 
The IP telephony network includes a plurality of ingress and egress gateways, at least one 
Session Initiation Protocol (SIP) proxy server (SPS) and at least one redirect server (RS). A 
dynamic gateway selection (DOS) feature is always active and is typically invoked whenever a 
source user agent (SUA) initiates a call attempt by sending a session participation request to the 
SPS. 

The preferred method generally includes the steps of: receiving a call setup request at the 
SPS from the SUA . The SPS forwards the request to the RS to obtain information of destination 
gateways. The R responds to the SIP session participation request with either a redirection 
response or a reqv^st failure response. The RS redirection response includes a routing list. The 
routing list is a list of egress (i.e., destination) gateways that arc determined to be in-service.. 
Upon receipt of a redirection response from the RS. the SPS proxies the session participation 
request to a first destination gateway in tbe routing list. Otherwise, the RS returns a failure 
response which is sent to the SUA. The failure response is an indication that there are no 
destination gateways having an in-service status. 

When the SPS proxies the request to a destination gateway, the SPS waits for a final 
response from the selected destination gateway. The SPS will either receive a final response or 
time-out. When the SPS receives a final response from the destination gateway, the SPS proxies 
the final response to the SUA, awaits an acknowledgment and proxies the acknowledgment. 
Otherwise, when the SPS times-out waiting for a final response from the destination gateway, . 
the SPS re-sends the request a predetermined number of rimes. If the SPS times-out for a final 
time, the SPS sends the session panicipation request to the next destination gateway in the 
routing list provided by the RS. 
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The process of sending a requesi a predetermined number of times is repeated for the 
next destination gateway in the routing list until one of the following occurs: (I) a success 
response is returned: (2) the SPS times-out waiting for a final response, as described above with 
respect to the first destination gateway in the routing list: (3) the SPS receives an unsuccessful 
final, non-server failure response from the currently selected destination gateway; or (4) the 
destination gateway returns a server failure response, in which case the SPS informs the RS of 
the destination gateway failure. 

In case of the second to fourth situations, the SPS sends the session participation request 
to other destination gateways in the routing list provided by the RS. For each destination 
gateway that returns a gateway failure response to the SPS. the destination gateway is recorded 
as an out-of-service destination gateway in the RS and is dynamically removed from the routing 
list Therefore, subsequent requests are not sent to destination gateways which are recorded as 
out-of-service destination gateways in the RS until after a predetermined amount of time. After 
the predetermined amount of time has elapsed, me RS automatically recovers failed or out-of- 
service pathways and issues a report to a network management system (NMS) indicating that the 
destination gateway is back in service. Table structures, stored within the RS. are updated on 
a real-time basis when it is determined that a gateway is out-of-service or back in-service. When 
the session participation request has been sent to all destination gateways and no successful 
response is received, the SPS returns a final response to the originating agent or calling party 
indicating that a call cannot be made. r 

tn an alternative method, availability of destination gateways is determined using a ping 
method. In this method, gateway availability is determined by sending at least one packet to 
each destination gateway to ascertain whether the destination gateway is available, or in-service. 
If the destination gateway is in-service, it transmits an ACK. message. If an ACK message is 
not received after a predetermined period of time, the destination gateway (DGW) is determined 
to be unavailable. The ping method preferably queries each destination gateway one-by-one and 
updates gateway information tables by recording the status of each destination gateway. 

The present invention thereby provides several functions, including: (1) dynamic 
detection of failed and unavailable gateways; (2) dynamic removal of failed and unavailable 
gateway(s) from a routing list, gateway information table, etc., after a predetermined period of 
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time; and (3) automatic recovcty of failed and unavailable gateways by updating gateway status - 
tables after a predetermined period of time. 

BRIEF DESCRIPTION OF TH E DRAWINGS 

Various preferred embodiments are described herein with reference to the accompanying .. 

drawings, in which: 

FIG. I is a block diagram of a preferred embodiment of the present invention; 

FIG. 2 is a flowchart illustrating signaling and call setup procedures according to the 

embodiment of FIG. 1 ; 

FIG. 3 is a call flow diagram illustrating the signaling and call setup procedures 

according to the embodiment of FIG. 1 ; and 

FIG. 4 is a flowchart illustrating an alternate embodiment of the present invention. 

DF.TAIL.ED DESCRIPTION OF THE PREFE R*" EMBODIMENTS 

Preferred embodiments of the present invention will now be described with reference to 
the figures where like reference numbers indicate identical or similar elements. It will be 
apparent to persons skilled in the relevant art that the present invention can operate on many 
different types of networks without departing from the scope of the present invention. In the 
preferred embodiments described herein, the I? telephony network is preferably the Internet 
Other examples of networks which could be used include leased lines, frame relay, and 
asynchronous transfer mode (ATM) networks. 

The present invention provides a method and system for selecting an egress or 
destination gateway to establish a communication session over a path supported at least in part 
by an IP telephony network, such as a WAN, and a PSTN, PBX or other network. The method 
further determines the status of a destination gateway, particularly, as being cixher in-service or 
out-of-service. and automatically brings a destination gateway back into service from an out-of- 
service state after a predetermined amount of time. 

Referring now to the drawings, and first to FIG. 1, a system according to a preferred 
embodiment of the present invention is designated generally by reference numeral 10. System 
10 is' a telephony network system and includes a first public switched telephone network (PSTN) 
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10 



15 



20 



25 



U4a which interfaces, an IP tdephony netwo* or I— 1 a The Internet, .2 - 
i^eed » a second PSTN .Hb. * first rSTN „4a includes a source user a^n, ( 
102. i.e.. originating agent, ivhich originates a session participation request. ^ ^^^^ 
, ,4b includes a called par* destination use, agent iDUA ,03). The Internet 
redirect serves (RS) 104. an SIP proxy serv.r<SPS> .06, aNetwo* Management System (NMS 

mrm n Oa 1 10b While only wo DGWs are shown, one of 
108. and destination gateways (DOWs) 110a, HOo. mr .n, eRsl0 4 
ordiM ry skill in the art win recognize that additional DOWs may he provided .O. RS « 

t . ,. „ m tu, una. nob. Status changes are reported 

receivesandstoresaUstatuscnangesregardutgDGWsllOa.ltuo 

tomeNMS 108by<heRS 104 via.be SPS 106. SPS 106 ac* as bod, a server and chen. for the 
^ o, ma** requests on beharf of other eiient, SPS 106 provides proxy server and 

c ,^„c <5PS 106 mav be a SIP proxy server or an H.323 
gateway resource management functions. SPS 106 may o ^ 

method of the present htvention (U., dynamic gateway selection (DOS) and 
^oval) is performed by the SPS 106 and RS 104 in context with the NMS 108 in order io 
aUowcaUsrobetouredrooneoftheDOWs 110a, 110b. The dynamic gateway selection and 
^oval feature is partly invoked upon receipt by the RS 104 of a session participation 
request The SUA 102 initiates a call anempt <o trausn.it the session participation request to the 
SPS 106. Accordingiy, an attempt is made to eaablish a contention session berwaenshe 
SUA 102 .ocated in she first PSTN 1 14a and the ceiled party desunarion device (DUA) 103 
located in the second PSTN 114b. PSTN 114a and 11 4b are bridged via the Internet 112. \ 
FIG. 2 is a flowchart illuaradng the call routing logic for establishing a commumcauon 
session in accordance with the methodology of me present invention. At step 702. a us,r 
inWatts a call attempt by sending a session participation request (i.e„ an INVITE request) to rite 
SPS 106. When rite INVITE request is an initial request rhe SPS 106 forwards the initial 
INVITE request ro rhe RS ,04fortou,inginstn K rionsats,ep704. AtstepTOS.itisdetennmed 
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whether there is at least one DGW that can satisfy the request. If so. at step 706. the RS 104 
responds to the SPS 106 query with arouting lis, i.e.. a list of candidate DGWs that can handle 
the call. The RS 104 supplies the routing list from a gateway information table stored therein. 

In the event the RS 104 determines that there are no DGWs that can satisfy the INVITE 
request, at step 705, a request failure response is returned to the SUA 102. at step 707. Upon 
receiving the routing list, the SPS 106 proxies the INVITE request to one of the DGWs 110a, 
110b. At step 708. the SPS 106 selects the first DGW 1 1 0a in the routing list to determine its 
serviceability and/or availability status. Steps 710 and 712 determine whether the currently 
selected DGW 1 10a from the routing list is in a failure state or has timed out. Specifically, at 
step 710, a determination is made concerning whether the DGW 1 10a returns a failure response 
(i.e.,out-of-service response). If there is a failure response at step 710, the SPS 106 reports the 
gateway fai^e- the RS 104 at step 714. The RS 104 marks the selected DGW 1 1 0a as an out- 
of-servicc- Uestir.ition gateway in a gateway information table stored in the RS 104. at step 716. 

In addition, the SPS 106 sends a message, (i.e., Simple Network Management Protocol 
(SNMP) trap) to the NMS 108 indicating a destination gateway failure. The SPS 106 then 
selects the next DGW 1 10b in the routing list, at step 718. Control then returns to step 710 to 
determine the availability of the next selected DGW 1 1 0b; that is, whether the next selected 
gateway UObis ma failure state or has timed out. If the next selected DGW 1 10b returns either 
a failure response at step 710, or times-out at step 712, then steps 714-718 are repeated. In short, 
me process of selecting a gateway from the routing list and determining whether it is in a failure 
state or has timed out is repeated until a DGW is found from the routing list which accepts a calT 
withasuccessresponseatstep720. When a success response is received, the SPS 106 forwards 
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the response to the nailing use, SUA 102 a< step 722. The media stream for the call is then s«' 
up at step 724 to establish a communication link between the SUA 102 and DUA 103. 

FIG: 3 is a call routing How diagram illustrating in grearer detail the call routing logic 

procedure described above with reference » FIO. 2. Table . be.ow lists the INVITE refuted 

pa.ame.er 6elds in the preferred embodiment when a SUA 102 initiates a call attempt by sending 

a session participation request I 

FIG. 3, step '-'a"). 



(i.e.. an TNVITE request) to the SPS 106 (See FIG.l, item 1 and 



Table 1 



Parameter 


Usage 


Request-Line 


Contains the method (e.g., INVITE), Request Uniform Resource 
Identifier (i.e., Request-URI) of the SPS and protocol version 


To 


Contains the address of the recipient of the request 


From 


Contains the address of the initiator of the request 


Call-ID 


Uniquely identifies the invitation 


Cseq 


Contains the request method and a decimal sequence number 
chosen by the requesting client, unique within a single value of 
the Call-ID 


Via 


Indicates the path taken by the request so far . 



The SIP INVITE is addressed to the called party DUA 103 at a proxy address at the SPS 
106. The SIP INVITE specifies the real IP address of the DUA 103. Upon receipt of the SIP 
INVITE, the SPS 106 sends a 100 trying message to the ingress or origination gateway 105 
(FIG. 3, step - V). Table 2 lists the mandatory fields associated with the 100 trying response 
message in the preferred embodiment. 

Table 2 
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ST*™ CoA* = 100. Reason phrase and protocol version 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Content copies from the original request message 


Cseq 


Content copies from the original request message 


Via 


Indicates the path taken by the request so far. Add the received- 
tag parameter if the previous address is incorrect in the via header 
1 field 



The SPS 106 counts the number of INVITE requests received. When a received request 
message does not contain a route header field, it is determined to be an initial INVITE request 
message. In such a case, the SPS 106 performs the following steps: (1) if a Topmost Via Header 
(TVH) source address is incorrect, adds a "Received" parameter (or replaces the existing one if 
there is one) with the source package to the Via header field inserted by the previous hop; (2) 
generates an internal Call-ID; or (3) forwards the requested message to the RS 1 04 (See FIG. 1, 
item 2 and FIG. 3, step V). Table 3 lists the required fields in the RS INVITE request message. 

Table 3 



Parameter 


Usage 


Status-Line 


Content copied from the original request message 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Internally generated Call-l 


Cseq 


Content copied from the original request message 


Via 


Add the received tag 



In response to receiving the RS INVITE request message from the SPS 106. the RS 104 
performs the following: [X) counts the number of INVITE messages received; and (2) determines 
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15 



that the user portion of Request Uniform Resource Identifier (i.e.. (Request-URJ) is less than or 
equal to IS digits and does not contain a leading 0 or 1. The gateway information table stored 
in RS104 is used to create an updated routing list. 

For example, when a gateway address is marked as out-of-service in the gateway 
information table stored in RS 104 and its associated rime value is zero, the gateway address is 
not added to the routing list. When the gateway address is marked as out-of-service in the 
gateway information table and its associated time value is greater than the current absolute RS 
time, the gateway address is not added to the routing list. When the gateway address is marked 
as out-of-service in the gateway information table and its associated time value is less than or 
equal to the current absolute RS time, the gateway address is added to the routing list and the 
. gateway address is marked as in-service in the gateway information table. The RS 1 04 also sends 
a message, i.e., the Simple Network Management Protocol (SNMP) trap, to the NMS 108 
indicating that the DG W is in-service. If there is only one gateway in the routing list, the RS 104 
will send a 302 response message back to the SPS 106 (See FIG. 1 , item 3 and FIG. 5. step "d"). 
The RS 104 increments a counter which counts the number of 3xx messages sent Table 4 lists 
the required fields in the 3xx (302 in the present case) response message and an example of the 
contact address list. 

Table 4 



Parameter 


Usage 


Status-Line 


Status Code - 302, Reason phrase and protocol version 


To 


Content copied from the Original INVITE request 


From 


Content copied from the Original INVITE request 


Call-ID 


Content copied from the Original INVITE request . 
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♦ •» 



Cseq 


Content copied from the Original INVITE request 


Via 


Content copied from the Original INVITE request 


Contact 


Multiple gateway addresses 



1 1 
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Table 5 lists the required fields in the SNMP trap message to the NMS. 

Table 5 



Parameter 


Usage 


Protocol Data 
Unit(PDU) Type 


Indicates that this is a Trap PD 


Enterprise 


Identities the network-management suosysiciu mai gcuc»<u6u 
the trap. Its value is taken from sysObjectID in the system 
Group 


Agent-addr 


The IP address of the object generating the trap 




6 = enterpriseSpecific. This value signifies that the sending 
protocol entity recognizes that some enterprise-specific event 
has occurred. The specific-trap field indicates the type of 
trap 


Specific-trap 


A code that indicate more specifically the nature of the trap 


Time-stamp 


The time between the last (re)initializaiion of the network 
entity that issued the trap and the generation of the trap 


Variable bindings 


The address of the gateway that returned the 5xx response 
and status (iri-service) 



In the case where there is more than one gateway in the routing list, the RS 1 04 sends a 
300 response message, instead of a 302 response message for a single gateway, back to the SPS 
106. For a 300 response, the RS 1 04 also counts the number of 3xx responses sent. Table 6 lists 
the required fields in the 300 response message and an example of the contact address list. 
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Table 6 



Parameter 

btatus-uine 


Status Code - 300. Reason phrase and protocol version 


TO 


<5flmp the original INVITE 


From 


Content copied from the Original INVITE request 


Call-ID 


Content copied from the Original INVITE request 


Cseq 


Content copied from the Original INVITE request 


Via 


Content copied from the Original INVITE request 


Contact 


Multiple reachable addresses 



The SPS 106 counts the number of routing responses received from the RS 104. The 
SPS 106 sends an INVITE to the first DGW 1 10a, and inserts the "user=phone" header in each 
contact list address (See FIG. 1 , item 4 and FIG. 3, step V). Table 7 lists the required fields of 
the INVITE request sent from the SPS 1 06 to the DGW 1 1 0a. 

Table 7 



Parameter I 


Usage 


Request-Line 


Contains the method (e.g., INVITE). Request-URI using the 
gateway from the top of the unused contact list and protocol 
version 


To 


Content copied from the original request message 


From 


Content copied from the original request message 


Call-ID 


Content copied from the original request message 


Cseq 


Content copied from the original request message 


Via 


Add the NS URL to the top 


Record Route 


Request-URI of the NS 
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The SPS 106 may receive a 100 trying response (see FIG. 3, step T) or a 180 ringing:, 
response from the DGW 1 1 Oa (See FIG. 3. step "g">. T*to 8 lists the required fieids of the 180; 
ringing response. 

Table 8 



Parameter 


Usage 


Status-Line 


Status Code = 1 80, Reason phrase and protocol version 


To . 


Same as the original INVITE request plus tag 


From 


Same as the INVITE request sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Via 


1 Same as the INVITE request sent to the Egress Gateway 



After receiving the 1 80 ringing response from the DGW 1 10a, the SPS 106 removes 
itself from the top of the Via field, re-starts the invite User Agent (UA) timer if it exists, and 
forwards the 180 ringing response to the ingress gateway (See FIG. 3, step V). The response 
message is sent to the address indicated in the Via header field. Table 9 lists the required 
message elements. 

Table 9 



Parameter 


Usage . __ 


Status Line 


Content copied from the' 1 80 response received from the gateway 


To 


Content copied from the 180 response received from the gateway 


From 


Content copied from the 180 response received from the gateway 


Call-ID 


Content copied from the 180 response received from the gateway 


Cseq 


Content copied from the 180 response received from the gateway 


Via 


Content copied from the 180 response received wiih the removal 
oftheNSURL 1 



14 



WO 01/84794 



PCT/US01/14272 



10 



The SPS receives an INVITE response (i.e.. 200 OK response) from the DGW 110a (See 
FIG. 3. step "hi"). Table 10 lists the required fields in the INVITE message. 

Table 10 



Parameter 


Usage 


Status Line 


Status Code = 200, Reason phrase and protocol version 


Jo 


Same as the original INVITE request plus tag 


From 


^ >u TKTVT-nr r^usst sent to the Egress Gateway 


Call-ID 


Same as the INVITE request sent to the Egress Gateway 


Cseq 


Same as the INVITE request sent to the Egress Gateway 


Record Route 


Request-URIoftheNS . ■■ 


Contact 


The reachable address of the Egress Gateway 



After receiving the 200 OK response from the DGW 1 10a, the SPS 106 performs the 
follow^ step,: . I) cancels the invite UA timer, if it exists; (2) removes the SPS URL from the 
Topmost Via Header (TMVH) field; (3) adds the next hop's Request-URl at the top of the 
record-route header field when either of the following conditions are met: a) there is no contact 
header field in the 200 OK response, or b) the SPS URL is on the top entry of the record-route 
header field; (4) counts the number of 200 INVITE responses sent by the SPS 106; and (5) the 
SPS 106 starts the ACK timer. The SPS 106 forwards the INVITE response (i.e., 200 OK 
response) to the ingress gateway (See FIG. 3, step "hi")- Table 1 1 lists the required headers in 
the INVITE response. 
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Table 1 1 



Parameter 
Status-Line 



To 



From 



Call-ID 



Cseq 



Via 



Record Route 



Usage . 

Status Code = 200. Reason phrase and protocol version^ 



Same as the original INVITE request plus tag 



Same as the TNVTTF. request sent to the Egress Gateway 



Same as the INVITE request sent to the Egress Gateway 



Same as the INVITE request sent to the Egress Gateway 



Content from the INVTTE request sent to the Egress Gateway 



Request-URI of the NS 



i.. 



The reachable address of the Egress Gateway 
The SPS 106 receives an ACK response from the ingress gateway and stops the ACK 
The SPS 106 counts the number of ACK response messages received by the SPS 106. 
Table 12 lists the required headers of the ACK response (See Fig. 3, step "k"). 

Table 12 



timer. 





Parameter 


Usage 


Request-Line 


Contains method (e.g., ACK), Request-URI of the NS and 
protocol version ! _ 


To 


Same as the original INVITE plus the tag 


From 


Same as the original INVITE 


Call-ID ' 


Same as the original INVITE 


Cseq 


Same sequence number as the original INVITE 


Via 


UA originated 



10 The received ACK response may contain a route header field. The SPS 106 either 

proxies the ACK response using the address in the route header or uses the address in the "To" 
header to determine whether to proxy the ACK response or consume the ACK response. The 
ACK response will be consumed when the "To" header address is equal to the SPS address, and 
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no to ute header e*i*s in the ACK response. When «,« SPS .06 define, that the ACK 
„e proxied. the SPS 106 performs rhe following: U) the SPS 106 add, the 



response should 



ACK's address to the top of the 



route 



header field: (3) the Request-URI is set to 



Via field: (2) the SPS 1 06 removes the top address from the 
foe address located at the top of the route header , 



• <• «^tnrheDGW 1 10a based on the top address in the 
field- and (4) the ACK message is forwarded to the U^w uva 

^headexfi^ 

T> Accordingly, the DGW 110a is selected as the available gateway for completing the call. 
If the DGW 1 lOt is determined to be unavailable, the same method outlined above is used to 
determine if DGW 110b is available, if neither DGW is available, a message is sent to the SUA 
^thatthecallcannotbecompleted. Table 13 lists the parameters of the ACK request message 



15 



sent to the DGW 110a. 



Table 13 




Content copied from the ACK received from the Ingress 
Gateway 




to »o*er preferred merhod. a DOW is selected using a ping medrod. In .his 
enrbodW, gateway availability is determined by sending at least one packet to each 
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destination gateway to ascertain whether the destination gateway is available, or in-service. 
Accordingly, if the destination gateway is in-service, it transmits an ACK message. If an ACK 
message is not received after a predetermined period of time, the DGW is determined to be 
unavailable. The ping method preferably queries each destination gateway one-by-one and 
updates a gateway information table by recording the status of each gateway. For example, if 
the ACK message is received, the DGW is then checked to determine if it is available. If it is 
available, its address is stored in a gateway informaxion table, and the process repeats for the next 
DGW. 

FIG. 4 is a flowchart illustrating the methodology of an alternate embodiment of the 
present invention, i.e.. the ping method. A counter is initialized at step 800 to indicate the 
currently selected destination gateway from the routing list (i.e., i«l to the number of gateways 
in the routing list). In step 802, a message is transmitted from a server (e.g. proxy server, 
redirect server) to the ith destination gateway for the purpose of obtaining a response. In step 
804 the server awaits a response from the ith destination gateway. Step 806 is a determination 
step to determine whether a response was received from the ith destination gateway. If a 
response is not received within a predetermined amount of time, the process continues to step 
807 where the ith gateway is marked as out of service or unavailable. In step 808, it is 

» 

determined whether there are additional destination gateways to check from the routing list. If 
not, the process terminates at step 810. Otherwise, the counter is incremented to select a 
succeeding destination gateway from the routing list at step 812. 

Steps 802-806 are then repeated to check the response and/or availability of the 
succeeding (i.e. ith + 1) destination gateway from the routing list, [fit is determined at step 806 
that a response is received within the predetermined time, the process continues to step 814 
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where h is then tether deemed whether the ponding destination gateway is avails or 
„„, lf.be destination gateway is no, stable. d»« process returns «o step 807 where the 
destination gateway b marked as out of serviee or unavailable. In step 80S. i. is then determined 
whether, are additional destination gateways to check ftom the routing list. If so. steps 802- 
806 are repeated for the succeeding destination gateway. Otherwise, if i, is determined at step 
814 that the responding destination gateway is available, the process condones a. step 816 where 
4. destination gateway is marked as available in a gateway stan* table. The process mum* to 
aep 808 to determine if there are additional destination gateways to be checked in tire routing 

list 

What has been described herein is merely illustrative of the application of the principles 
of the preset,, invention. For example, the (motions described above for operating the ptesen, 
invention a:c T illustration purposes only. Other atrangements and methods may be 
implemec-ed bj those skilled in the art without departing from the scope and spirit of the 
invention. 
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WHAT IS CLAIMKHJS- 
\ 1 . A method for routing calls to a destination gateway to establish a communication 

session call in a Telecommunications network over a path supported at least in part by a telephone 
network and an IP network, said IP network including a plurality of ingress and destination . 

4 gateways,atleastonep ro ^ 

5 the steps of: 

6 . a) receiving a call setup request at the at least one proxy server from a source user 

7 agent; 

8 b) forwarding the received call setup request to the redirect server to obtain 

9 routing information; 

I o c) responding to the forwarded call setup request received at the redirect, server 

II by returning said routing information or a request failure response; 

1 2 d ) proxying the call setup request by the at least one proxy server to a destination 

13 • gateway selected from said routing information upon receiving the routing information from the 

14 redirect server; 

e) upon proxying the call setup request by the at least one proxy server to the 
selected destination gateway, waiting for a response at the at least one proxy server from the 
17 selected destination gateway; 

<, Q f) upon said at least one proxy server receiving the response from the selected 

. 1 9 destination gateway within a predetermined time, establishing a communication session using 

i 

20 said selected destination gateway; and 

21 g) if the response is not received within the predetermined time, sending the 

22 call setup request to a succeeding destination gateway selected.from the routing information, 

20 
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2. The meihod as claimed in claim I . further comprising repealing steps (d) to (g) 
until a destination gateway is determined to be available for establishing said communication 
session or until all destination gateways from said routing information have been determined to 
be unavailable. 

3. The meihod of claim 1, further comprising the steps of: 

• recording a destination gateway status as unavailable if response from said 
destination is not received within the predetermined time; and 

recording a destination gateway status as unavailable if the response from said 
selected destination indicator the destination gateway is unavailable. 

4. The method as claimed in claim 3, wherein said step of recording records 
said destination gateway status as out-of-service in a gateway information table stored within 
the RS. 

5. The method as claimed in claim 1, wherein said step of receiving a call setup 
request at the at least one proxy server from a source user agent includes the step of addressing 
said call setup request to a proxy address of the at least one proxy server. 

i 

6. The method as claimed in claim 1. wherein said step of receiving a call setup request 
at the at least one proxy server from a source user agent includes the step of counting a number 
of received requests subsequent to said call setup request at the at least one proxy server. 
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7. The method as claimed in claim I. wherein me at least one proxy server 
comprises a Session Initiation Protocol (SIP) proxy server. 

8. The method as claimed in claim I. wherein the at least one proxy server 
comprises an H.323 gatekeeper. 

9. The method as claimed in claim I, wherein said step of responding to the 
forwarded call setup request from said at least one proxy server received at the RS includes 
detennining the status of a group of destination gateways. 

10. The method as claimed in claim 9, wherein the status of each of said group or 
destination gateway is one of in-service and out-6f-service. 

11. The method as claimed in claim 10, wherein if the destination gateway status is 
recorded as out-of-service in a gateway information table and its associated time value is greater 
than a current absolute RS time, the gateway address is not added to a routing list of said routing 
information. 

12. The method as claimed in claim' 10. wherein if the destination gateway status is 
recorded as out-of-service in a gateway information table and its associated time value is less 
than or equal to the current absolute RS time, the gateway address is added to a routing list of 
said routing information and recorded as in-service. 
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13. The method as claimed in claim 10. further including the step of sending a 
message from the RS to a network manager to record the status of a destination gateway. 

14. The method as claimed in claim 1. further comprising the steps of forwarding a 
request Mure response to the source user agent upon receiving the request failure response froth 



the at least one proxy server, and terminating the communication 



session. 



15. The method as claimed in claim 1, further comprising the step of re-sending the 
call setup request to the selected destination gateway a predetermined number of times when the 
response is not received within the predetermined time. 
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1 1 6. A system for allowing a call to be completed in a communication session between 

2 a calling party and a called party, which comprises: 

3 . a first telephony system including at least one service user agent (SUA); 

4 a second telephony system including at least one destination user agent (DUA); = 

5 an IP network connected between said first and second telephone systems, 

6 a plurality of ingress gateways for interfacing said IP network to said first 

7 telephony system; 

8 a plurality of egress gateways for interfacing said IP network to said second 

9 telephony system; 

10 an IP telephony proxy server for selecting one of said plurality of egress 

1 1 gateways for completing said call; 

■j 2 an IP redirect server for providing routing information to said IP telephony 

13 proxy server, and 

-1 4 a network management system for receiving and storing status changes of 

1 5 destination gateways, said network management system being in communication with said IP 

16 redirect server. 

1 17. The system as claimed in claim 16. wherein the IP telephony proxy server is a 

2 Session Initiation Protocol (SIP) proxy server. 

1 1 8. The system as claimed in claim 1 6, wherein the IP telephony proxy server 

2 is an H.323 gatekeeper. 
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1 19. A method for detecting an available destination gateway from a plurality of 

2 destination gateways in an IP network for completing a communication session between a calling 

3 party and a called party, said method comprising the steps of: 

4 a) transmitting a message to one of said plurality of destination gateways . 

5 from a server to ascertain an availability status of said one of said plurality of destination 

6 gateways; 

7 • b) waiting for an acknowledge response from said one of said plurality of 

8 destination gateways for a predetermined period of time; 

9 c) determining if said one of said plurality of destination gateways is 

10 available if said acknowledge response is received within said predetermined period of time and 

1 1 indicates that the destination gateway is available; and 

12 d) . transmitting said message to a succeeding gateway of said plurality of , 

1 3 destination gateways. 

1 20. The method as claimed in claim 1 9, further comprising repeating steps (b) to (d) 

2 until the availability status of each of said plurality of destination gateways has been determined. 

1 21. The method according to claim 19, wherein if said acknowledge response is not 

2 received within a predetermined period of time, said availability status of said destination 
• 3 gateway is said to be out-of-service. 
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, 22. The method according to claim 19. therein if said one of said plurality of 

2 destoion gateways is deterruuted ro be avaUable, then said availability status is determined ro 

3 be in-service. 
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